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[57] ABSTRACT 

A packet of data is received from a LAN and transmitted 
over a WAN, by retaining the native LAN frame format of 
the packet during transmission across the WAN. Tbus, LAN 
data may be transmitted over a SONET point-to-point link 
within a WAN network without the interim steps of creating 
ATM cells or other WAN transport packaging protocols. 
Instead, the LAN data may be transmitted directly over the 
SONET link as raw data, and reconstructed direcUy at the 
receiving end of the SONET link. A first buffer stores data 
from the LAN so that a corresponding packet size may be 
determined, and a second buffer stores data from the WAN 
to accoimt for any speed difference between the LAN 
circuitry and WAN circuitry. 
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METHOD AND APPARATUS FOR SONET may also be defined as an octet-synchronous 

TRANSMimNG LAN DAIA OVER A multiplex scheme that defines a family of standaid rates and 

SYNCHRONOUS WTOE AREA NETWORK formats. Despite the name. SONET ^ not limited to opUcal 

links. Electrical specifications have been defined for single- 

. ^ r A' ^rr. < mode fiber, multi-mode fiber, and CATV 75 ohm coaxial 

This IS ^^^f~°^^P^^f ' cable, m transmission rat^s are integral multiples of 

monly owned US. Ser. No. Oa/68U 13 filed on JuL ^ ^ be used to carry T3/E3 bit- 

1996, from which pnonty is claimed and which is hereby synchronouTsignals. The allowed multiples are cunentiy 

incorporated by reference in its entirety. specified as: 

BACKGROUND OF THE INVENTION lO 

1. Field of the Invention 

This invention relates generally to computer networking 
systems and more particularly to transmitting data &"om a 
local area network over a wide area network. 15 

2. Discussion of the Related Art 
Cbmputer networks are widely used to provide increased 

computing power, sharing of resources, and conununica- 

tions between users. Local area networks (LANs) may rNTT^ j ^ 

include a number of computer devices within a room, 20 The CCTIT Synchronous Digital Hierarchy (SDH) define a 

building, or site that are connected by high speed data links subset of SONET transmission rates, beginmng at 155.520 

such as token ring, cthemet, or the like. LANs have tradi- Mbps, as set forth below: 
tionally been interconnected by bridges, hubs, and switches. 

A Wide Area Network (WAN) may link together different 

LANs. A WAN typicaUy includes packet switches, micro- ^ ^^^^ni 

^2LVt links, and satellite links. Thus, a network may include — — 

several hundred or more interconnected devices (nodes), ^^^"^ S^l"? 
distributed across several geographical locations, and 
belonging to several organizations. 

wi^L^^TelT^t^^^r " AS dc^^. SON^ can be used ui k^p^er, local 
necting a va/number of nodes, but generaUy at a slower ^^^^^^^^^ ^fe'^^eS coupled 
speed. Therefore, LAN transport mechanisms and protocols ^^^^J |^ ^ ^^^^ ^chronous mulUplexing mode, 
are typically not appropnatc for use on a WAN. SONET line signals 21 are transmitted across the SONET 
, FIG. 1 shows an example of an arrangement in which a digital cross-connect system 20. SONET terminal multiplex- 
WAN couples together several LANs. In particular, FIG. 1 22, 24 receive tributary signals 23, for example from 
shows WAN 10 connecting LAN A, LAN B and LAN C. A sourcc'and destination computers, and provide the SONET 
LAN/WAN interface 12 provides translation, data signals. 

formatting, and/or other protocol-related functions so that ^ advantage of the SONET standard is that individual 

source and destination computers on LAN A may interface tributary signals may be accessed within the structure of the 

with source and destination computers on LAN B and LAN multiplexed SONET line signal. For example, SONET add- 

C. Similarly, LANAVAN interface 14 allows LAN B to be mult^lexers 26 and 28 may each provide data from 

coupled to WAN 10, and LAN/WAN interface 16 aUows ^j^^^ rc^ective tributary signals 25 onto the SONET digital 

LAN C to be coupled to WAN 10. 45 cross-conned system 20. 

One method of interfacing a LAN to a WAN is to provide The building block of the SONET protocol is a synchro- 

a router-specific interface which substitutes a WAN physical qous transport frame 30, shown in FIG . 3 . Frame 30 includes 

link layer and a proprietary data Unk layer in each LAN data transport overhead 34, and synchronous payload envelope 

message, and rate-converts the LAN messages to WAN (SPE) 32. Although data is transported serially, the franae 30 

compatible speeds. Then the messages may be transmitted 59 is typically represented by a two-dimensional map with N 

across the WAN. A drawback to such an approach is that rows and M columns; a byte is provided at each row/column 

many of the high-capacity networks that provide high-speed intersection. The signal bits are transmitted starting with the 

communications within the WAN are inflexible and expen- byte in the upper left hand comer of the frame 30, followed 

sive. Additionally, there is very limited network manage- by the second byte in the top row, ete., until all of the bytes 
ment and maintenance support capabilities, and very little, if 55 of the first top row are transmitted. The second and subse- 

any, spare signal capacity within frame stmctures, in the quenl rows follow transmission of the first row in the same 

WAN protocol Thus, this technique is generally very expen- manner. 

sive and slow. The SPE 32 includes individual tributary signals, and is 

SONET (Synchronous Optical Network) is a standard for designed to traverse a SONET network from end to end. The 
a high-capacity opUcal telecommunications network. It is a 60 SPE 32 is assembled and disassembled only once, even 

"synchronous digital transport system intended to provide a though it may be transferred from one transport system to 

more simple, economical and flexible network infrastruc- another (i.e., between several SONET network nodes) many 

mre. The Phase 1 SONET standard issued in March 1988, times on its route through the SONET network, 

and is defined in "American National Standard for Some signal capacity is aUowed in each frame 30 for 
Telecommunications-Synchronous Optical Network 65 transport overhead 34 to provide support and maintenance 

(SONET) Paybad Mappings", ANSI T1.1Q5 .02-1993 draft, facilities, such as alarm monitoring, bit-error momtonng, 

which is incorporated by reference. and data communications channels. Transport overhead 34 
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typicaUy pertains only lo an individual iran^rt system and In one embodiment, an interface is provided ^tween a 

is not transferred when the SPE 32 is transferred between first network and a second network, mcludmg a fii^ mtcr- 

H.ooo««rt cvcti^mc face device, a second interface device, an input buffer, and 

10.4%. This is a relatively large amount of overhead, when ^ . ^ ^^^^ receives and stores a packet from the 

compared to a typical LAN packet. FIG. 4 shows an ATM interface device. A control circuit is coupled between 

cell 40, in which 48 bytes of ATM data 44 are transmitted lO interface device and the second interface device, and 

with a 5-byte ATM header 42. In accordance with the ATM ^ coupled with the input buffer. The control circuit deter- 

standard, an ATM cell always has 53 bytes. mines a length of the packet and provides the packet and an 

FIG. 5 shows a SONET synchronous transport frame 49 indication of the length of the packet to the second interface 

that inchides ATM cells. The synchronous transport frame device. The second interface device transmits the packet and 

49 inchides SPE 53 and a transport overhead 48 which is indication of the length of the packet across the second 

inchides section overhead 50, pointer 52 and line overhead network 

51. The pointer 52 is a reference which indexes the starting Another embodiment of the invention is directed to a 

point of the SPE 53. SPE 53 includes path overhead 54, method for transmitting data from a first network to a second 

ATM cells 55A, 55B, 55C, 55D, and 55E, and other data. network, comprising the steps of receiving a data packet 

During times for which there are no ATM cells to transmit, 20 ^^^^ ^ source on the first network, buffering the packet to 

an idle space is provided (see for example idle ^ace 56 provide buffered data, determining a length of the packet 

between two ATM cells 55D and 55E). In addition, because ^^^^ buffered data, and transmitting the packet and an 

an integer number of ATM cells may not fit within a given indication of the length of the packet across a third network 

SPE, there may be some empty space 57 (see FIG. 5) ^j^.^^j^ ^ coupled between the first network and the second 

following the last ATM cell, or otherwise dispersed within 25 Qet^oj-i^ ^ that the packet is received at the second nel- 

the SPE. work. 

FIG. 6 depicts a known process for converting LAN data ^et another embodiment is directed to an apparatus for 

to ATM cells for transport over a SONET network. In step transmitting daU from a first network to a second network, 

58, a LAN packet is received from a first IAN The LAN comprising means for receiving a data packet from a source 

packet is divided into 48-byte segments (step 59) m accor- 30 network, means for buffering the packet to 

dance with the fixed ATM cell size. An ATM 5-byte header ^ide buffered data, means for determining a length of the 

is added to each of the 48-byte segments (step 60) to create j^^^ buffered data, and means for transmitting 

a number of ATM cells. The ATM cells are packed mto a , ^ indication of the length of the padcet 

SONET SPE (step 61). The appropriate SONET tran^ort ^ nttwoxk which is coupled between the first 

overhead is then added to the SPE (step 62) to create a 35 ^^^^^^^ ^^^^ network. 

synchronous transport frame. The frame may then be trans- ^^^^ embodiments, a receive buffer may 

mittcd over the SONET-compatible network (step 63). ' differences between the first 

At another SONET mulUple^r. the -^-^ous tr^- ^^^^ ^^^^^^ AdditionaUy, a preamble may be 

port frame is '^^^f /^^P .^f ^ ^^^Xo 40 transmitted along with the data, and a fill pattern may be 

overhead is removed (step 65) to the SPE. It is then 40 ^^^^^^ when there are no packets to be transmitted. Tlie 

necessary to unpack the ^ aUs from the SPE m order to ^ ^ ^^^^^^ ^^^l 

provide ATM cells (step 66). Tbe ATM header is removed ^ transmitted as a contiguous data stream in a frame 

from each of the ATM cells (step 6^. V formal which is native to the local area network. TTie packet 

LAN packet daU be reconstructed from the ATM cell data transmitted by an interface device operating in a 

(step 68). The reconstructed LAN padcet may then be 45 ^^^^^ j^^^. ^.^^de that docs not require additional formatting 

transmitted onto */«=°°i^Lf^^P . ^ -fi^^. or encapsulation, other than that required to comply with a 

As IS evident from FIGS. 4-6, there is a significant tocolof the networkover which the packet is transmitted, 

amount of overhead which ^ required to transmit recon- advantages of the present 

stnicted LAN data over a SONET netwo^ invVn^nTha^ we^S^^ 

standani. Ttis overhead includes not only signal bandwidth, 50 invouuuu auoii ayy & 

for example the 5-byte AIM header added for each 48 bytes drawmgs. 

of data, but also significant processing time in order to BRIEF DESCRIPTION OF THE DRAWINGS 

divide the LAN packet, construct the ATM cells, and ulti- schematic illustration of a wide area network 

mately reconstrurt the LAN packet (WAN) connecting several local area networks (LANs); 

SUMMARY OF THE INVENTION FIG. 2 is a block diagram showing elements of a SONET 

net^iVork; 

In a preferred embodiinent of tbe present invention a ^ ^ ^^^^^ ^ synchronous tranH-ort 

method and apparati^ 8« iwovrfed for transmitting a pactet transmitted across a SONET network such 

of LAN data over a WAN. by retaimng a native LAN frame " 

format of the packet across the WAN. Tbus, data received 60 '^^^ ^n^. \° , . , atm 
fern a LAN may be transmitted over a SONET point-to- FIG. 4 depicts the contents of ^ ^ 
pltlinkwithoJtheinterimstepsofcreatingAmceUsor FIG^5 Ulustrates an approach P»^°8 Am «lk m^ 
Suier reformatted message units. Instead, the LAN data may a synchronous payload envelope (SPE) withm a synchro- 
be transmitted directly over the SONET link as "raw data" nous transport frame such as that shown ui FIG. 3, 
(native LAN frame format) within SONET transport frames, 6S FIG. 6 is a flow diagram showing the known procws stejs 
and reconstructed direcUy at the receiving end of die required to transmit reformatted LAN data over a SONbl 
SONET link. network using the ATM standard; 
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FIG. 7 is a high-level block diagram of an embodiment of between LAN A and LAN B without formatting the packet 

the invention, in which a SONET network provides com- data into separate cells, such as ATM cells. The poinl-to- 

munications between two U\Ns; point link 75 may be a SONET link within the WAN 70, 

o - LI 1 J- r cnMCT/r am which is created and maintained by a conmumicaUons 

FIG. 8 IS a block diagram of a SONET/LAN mtertaoe, . 

such as that shown in HG. 7; 5 P"^^® ^ ^^^^ SONET/LAN interface 

FIG. 9 is a flow diagram of process steps for iransnutting ^3 ^ sqNET line transceiver 80 provides a physical inter- 

a LAN packet from one LAN network to another LAN face with the SONET network. Coupled to the transceiver 80 

network across a SONET network, which may be performed ^ ^ SONET framer/deframer with raw data capability 82. 

by the elements of the block diagram of FIG. 8; The "raw data** capability, also referred to as "native frame 

FIG. 10 illustrates more detail of one of the steps of FIG. format" capability, means that data can be transmitted across 

9, in which the LAN packet is packed directly into a SONET the SONET network without adding additional overhead to 

synchronous payload envelope (SPE) along with a packet the data other than the overhead which is required by 

length field* SONET. Examples of oveAead required by SONET inchidc 

FIG. n ilhistrates more detail of the one step of FIG. 9, 15 ^"^"^^ ^^J^^*^^^ mcluding payload pointers, path over- 

in which a LAN packet is unpacked from the SPE uang bead mcludmg secUon overhead and hne overhead, and 

information regarding the length of the LAN packet; virmd transport overhead mclucUng virtual paylo^ 

o^Krr^l -J -.k and virtual path overhead. In at least one SONET 

FIG. 12 sho^ a SONET frame m accordance with an overhead includes payload pointers, 

embodiment of the present mvention; automatic proleaion switching, parity check, alarm 

HG- 13 shows a mapping of LAN packets onto SONET 20 ^^£^^^^^0^^ section overhead includes frame alignment 

SPEs according to the invention; pattern, and STS identification, and parity check. 

FIG. 14 is a detailed schematic diagram of one apparatus When a data packet is transported in its native frame 

for implementing the invention; format, this means that the data packet is still recognizable 

FIG. 15 is a flow process diagram of steps performed by ^ (arranged) as it was when transported across a LAN. 

the Transmit FIFO Write Control Logic (1402) of FIG. 14; Typically, this also means that there is no additional over- 

FIG. 16 is a flow process diagram of steps performed by head interspersed within the data packet. In one 

the TVauMnit FIFO Read Control Logic (1410) of FIG. 14; embodiment, an interface device having ATM ccU proccss- 

FIG. 17 is a flow process diagram of steps performed by fV^^^^ operated iii a "^^^e .^^ic^^ 

the Receive FIFO Write Control Logic (1^) of HG. 14; 30 ^ ^^^^^^T^ T 1^^^^^^^^ 

i- i-ju provided by the mterface device. For example, the raw data 

FIG. 18 is a flow process diagram of steps performed by ^biUty may be invoked by selecting a test or diagnostic 

the Receive FIFO Read Control Logic (1430) of HG. 14; framer/deframer 82 (bypassing the 

FIG. 19 is a block diagram of another embodiment of the processing), 

invention; ^ ^^^^ formatter 84 is coupled between the framer/ 

FIG. 20 is a flow process diagram of steps performed by deframer 82 and LAN media access controller 86. The 

the apparatus illustrated in FIG. 19 when transmitting data controller 86 provides an interface to the appropriate LAN, 

to a SONET WAN; for example LAN A or LAN B shown in FIG. 7. 

FIG. 21 is a flow process diagram of steps performed by pjQ . 9 shows the process steps by wliich a LAN packet is 

the apparattis illustrated in FIG. 19 when receiving dau from ^ transmitted from a first LAN to a second LAN. In step 90, 

a SONET WAN; and the LAN packet is received from the first LAN. In step 91, 

FIG. 22 is a detailed schematic diagram of one embodi- the length of the LAN packet is determined, so that ulti- 

ment of the invention as shown in FIG. 19. malely the LAN packet may be unpacked on the receiving 

end. Such packet length may be defined as a number of 

DETAILED DESCRIPTION eight-bit bytes, but may also be defined as a number of bits. 

There are many businesses or organizations having two or or a number of 16-bit words. The LAN packet may be one 

more geographically-separated LANs between which much from an ethemet, FDDI, token ring, or other protocol. In step 

data is transmitted, HG. 7 shows an example in which LAN 92, the LAN packet and a packet length field are packed 

A is in a first location 71, such as a first building or campus, direcUy into a SONET synchronous payload envelope 

and LANs B and C are in a second location 72, such as a 50 (SPE). In step 93, SONET transport overhead is appended to 

second buikling or campus. WAN 70 provides communica- the SONET SPE to create a synchronous transport frame. By 

tions among these and several other LANs, for example using a packet length field, it is not necessary to iiiclude 

LAN D and LAN E. In this example, LAN A is coupled to delimiters indicative of the end of packet and beginning of 

WAN 70 by SONET/LAN interface 73A, and LAN B is packet, which would typically be inchided if the packet were 

coupled to WAN 70 by SONET/LAN interface 73B. LAN B 55 encapsulated within another format, such as the HDLC 

is also coupled to LAN C by bridge 74. LAN/WAN interface format. HDLC encapsulation would require significandy 

76 provides communicatiDns between LAN D and WAN 70, more overhead. 

and LAN/WAN interface 77 provides communications In step 95. the synchronous tran^rt frame is transmitted 
between LAN E and WAN 70. Suitable LAN/WAN inter- over a SONET^ompatible network- The synchronous trans- 
faces 76, 77 are known in the art 60 port frame is received, and the SONET transport overhead is 
The first SONET/LAN interface 73A, second SONET/ then removed (step 96) to yield the synchronous payload 
LAN interface 73B, and WAN 70 provide a point-to-point envetope SPE (step 97). Because the SPE includes a packet 
communications path 75 between LAN A and LAN B. In length fiekJ, the bytes of the LAN packet may be unpacked 
essence, the SONET/LAN interfaces 73A, 73B provide a from the SPE by unpacking the appropriate number of bytes 
bridge fimction between LAN A and LAN B, and also an 65 as determined by the packet length field (step 98). The 
effective intrface between LAN A and LAN C. The unpacked IAN packet is then transmitted onto the second 
SONET/LAN interfaces 73A. 73B transmit and receive data LAN (step 99). 
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As caD be seen from a comparison of FIG. 9 and FIG. 6, 
there is much less overhead and many less steps in the 
present invention, as compared with the ATM approach. 
Because there is no firagmentation of the original packet, 
except perhaps between successive SPEs, higher transfer 
rates are achievable while using less computer resources and 
costs. Thus, trananitting a LAN data padcet as a contiguous 
data stream contributes to more efficient communications. 

FIG. 10 diows more detail of an exemplary embodiment 
of step 92 of FIG. 9. in which the LAN packet is packed 
directly into a synchrotwus paybad envebpe. In step 100, a 
SONET frainer/defiramer is controlled to communicate in a 
raw data mode. In step 101, the native preamble for a first 
LAN packet is packed into a SPE, followed by a packet 
length field for the first packet (step 102). Then, the data for 
the first LAN packet is packed (step 103). If there are no 
more LAN packets available at this time, a fill pattern is 
packed into the SPE and subsequent SPEs, until a next LAN 
packet is available (stq) 104). The fill pattern may be 
selected to be easily distinguishable from a LAN preamble, 
as will be discussed in more detail below. Once a next LAN 
packet is available, the preamble is packed (step 105), the 
packet length field is packed (step 106), and the next LAN 
packet data is packed (step 107). 

FIG. 11 is an exemplary embodiment of step 98 of FIG. 
9, in whidi a LAN packet is unpacked from a synchronous 
payload envelope using informatbn regarding the packet 
length. Because the SONET framer/deframer is operating in 
a raw data mode, there may not be a specific signal indi- 
cating that a new packet is being received. Therefore, in one 
embodiment of the invention, a native preamble is detected 
within the raw data that is received from the SONET 
framer/deframer (step 108). This preamble detectbn is usu- 
ally performed by a device that is external to the SONET 
framer/deframer, so that the SONET framer/deframer is free 35 
to continue receiving the stream of raw data. Generally, a 
native (LAN) preamble includes alternating ones and zeros 
transmitted serially, but it is possible to use other sequences. 
After the preamble has been detected, the packet length field 
is provided from the SONET framer/deframer. Accordingly, 40 
in step 109, the packet length field is checked to determine 
the number of bytes in the LAN packet. Once the number of 
bytes in the LAN packet is known, the bytes may be 
provided to a LAN interface device (step 110). If a subse- 
quent LAN packet is not transmitted immediately after a 45 
previous LAN packet, then a fill pattern may be received 
from the SONET framer/deframer until a next preamble is 
detected (step 111). 

FIG. 12 iows one approach to formatting a variable 
length LAN packet into a modified form for direct trans- 
missbn as raw data over a SONET network- The modified 
packet 115 includes a LAN preamble 116, packet length field 
117, and variable length LAN data packet 118. In one 
embodiment, the preamble inchides 8 bytes, the packet 
length fiekl inchides 2 bytes, and the variable length LAN 55 
data packet may include any nimiber of bytes as determined 
by the packet length field 117. 

FIG. 13 shows an example of how several modified LAN 
packets may be transmitted across a SONET network using 
a number of SPEs. For example, the SONET data stream 
may include a first synchronous transport frame 120, that 
includes a first SPE 121. The first SPE 121 includes path 
overhead 122 and data 123; data 123 is a combination of 
LAN data and fill data. For example, the first SPE 121 may 
include a first modified LAN packet 130, which is followed 
by fill daU 131. This is an example of a case in which there 
was no data to transmit from a first LAN to a second LAN 



from the time that the first LAN packet 130 was sent until 
a second LAN packet is received. Following the fill data 131 
is a second modified LAN packet 132, which is immediately 
followed by third modified LAN packet 133. In this 
example, because the third modified LAN packet 133 docs 
not fit within the space still available in the SPE 121, only 
a first portion 133A of the third modified LAN packet is 
included within SPE 121. 

Following the first synchronous transport frame 120 is a 
second synchronous transport frame 124, which includes a 
SPE 125 having path overhead 126 and daU 127. The second 
SPE 125 inchides a second portion 133B of the third 
modified LAN packet 133. No additional overhead is 
required to define this split between the first portion USA 
and the second portion 133B because in the beginning of 
each modified LAN packet is the packet length field 117, 
which determines the length of the variable length LAN 
packet to follow. Thus, when the raw data is provided from 
the SONET framer/deframer, all that is required is to coimt 
20 the appropriate number of bytes to folbw, even if these 
bytes are overlaid on two differait synchronous paybad 
envelopes, as shown in the example depicted in HG. 13. 
Follovring the third modified LAN packet 133 is a fourth 
modified LAN packet 134. 

FIG. 14 is a detailed illustratbn of a SONET/LAN 
interfece 73. In this embodiment, a "LAN to Raw Data/ 
Framer" (LRDFRMR) 140 provides an interface between a 
"Switched LAN Media Access ControUer" (SLMAQ 142 
and a "Raw DaU to SONET Framer" (RDSFRMR) 143. The 
RDSFRMR 143 is further coupled to a "Parallel/Serial and 
Serial/Parallel Converter with Qock Synthesizer^ 145, 
which is fiirther coupled to "Fiber Optic Transceiver^ 146 
and '^Reference Clock" 147. The transceiver 146 interfaces 
with a SONET network 138, while the SLMAC 142 inter- 
faces with a LAN 139. Additionally, "Host PK>cessor" 144 
provides control functions to coordinate the functbnality of 
several of the elements of FIG. 14. 

In this embodiment, the RDSFRMR 143 is a 622 Mbits/ 
sec SONET Framer, Part No. PM5355, available from 
PMC-Sierra, Bumaby, British Columbia, Canada; the LRD- 
FRMR is a 20K field progranamable gate array. Part No. 
A32200BX, available from Actel, Sunnyvale, Calif., U.SA.; 
the Converter 145 is Part No. VCS8110, available from 
\^tcsse, Camarillo, Calif., U.SA.; and the Fiber Optic 
Transceiver 146 is Part No. HFBR5207, available from 
Hewlett-Packard, Burlington, Mass., U.S.A. The Host Pro- 
cessor 144 may be any general purpose processor, and the 
SLMAC 142 may be any device which provides appropriate 
interface with a LAN. 

The LRDFRMR 140 may also be implemented as a 
prxKiessor, any combination of firmware or software, or may 
be embodied as an ASIC or combination of discrete ele- 
ments. The components of the LRDFRMR 140 depicted in 
FIG. 14 are described below. 

The Transmit FIFO Write Control Logic 1402 provides an 
interface with SLMAC 142 when data has been received 
from the LAN 139 by SLMAC 142. In particular, Trananit 
FIFO Write Control Logic 1402 interfaces with a Transmit 
Packet Size Counter 1404 and a Transmit FIFO 1406. The 
Transmit FIFO Write Cbntrol Logic 1402 utilizes a clock 
emanating from a Qock Buffer 1408, which receives clock 
signals from SLMAC 142. 

The Transmit FIFO Read Control Logic 1410 provides 
data, that has been previously processed by the Transmit 
FIFO Write Control Logic 1402, to the RDSFRMR 143. 
Such data may be particularly provided by Transmit Register 
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1412 Multiplexer 1414 selects specific data from ihe Trans- CTransmii FIFO Not FuU). During this time, the periodic 

Tn^TS^^^^ selects either data transmit pulse f 

f.m the Transmit FIFO 1^^^^^^^^ fill panem data from the P^,-^^^^^^^^ 

FiU Pattern Data Generator 1418. the Transmit FIFO 1406 is transferred to the RDSFRMR 143 

The Receive FIFO Write Control Logic 1420 provides Multiplexers 1414, 1416, and Trananit Register 
control when daU is received from the SONET network via 

the RDSFRMR 143. In particular, the Receive FIFO Write Ouiiag step 162, status bits of the Transmit FIFO 1406 arc 
Control Logic 1420 controls the Preamble Detect Logic njonitorcd to determine the end of the packet as indicated by 
1422, the Receive FIFO 1424, and the Receive Packet Size ENDOFPKT. Additionally, during step 162, the pen- 
Counter 1426. odic transmit pulse is also generated, step 163, to maintain 

The Receive FIFO Read Control Logic 1430 then controls RDSFRMR 143 ninning in the raw daU mode. Al the end 

the Receive FIFO 1424, and the Receive Register 1432. to of the padcet, the Transmit FIFO Read Control Logic 1410 

provide the received data to SLMAC 142. checks to see if any transmit errors occurred (step 164). If no 

Exemplary operation of the structure depicted in HG. 14 errors occurred, then the last word of the data packet is seiit 

will be explained with re^t to operation of each of the to the RDSFRMR (step 165), If there is an error, the fill 

Control Logic Elements 1402. 1410, 1420, and 1430. In pattern from the Fill Pattern Generator 1418 is sent to the 

particular HG. 15 is a flow process diagram of steps RDSFRMR 143, as shown in step 166. After the final word 

performed by the Transmit FIFO Write Control Logic 1402. is written in either step 165 or 166, then the process ^ai^ 

The process begins by wailing for the SLMAC 142 to start ^ to step 161 which provides a fill pattern to the RDSFRMR 

a data transfer (step 150). This may be determined as an 143. , . u 

initial state by providing a reset signal. Upon receipt of a piG. 17 illustrates the process steps performed by the 

Transmit Eiiable Signal (TXEN) from the SLMAC 142. the Receive FIFO Write Control Logic 1420, to receive data 

Transmit FIFO Write Control Logic 1402 begins to load the from the SONET network via RDSFRMR 143. Hie process 

data received from the LAN into the Transmit FIFO 1406. ^ begins when the RDSFRMR 143 provides an indication that 

step 151 In one embodiment, the SLMAC 142 also provides jt has data. For example, this may be indicated by the 

an indication of the packet size of the LAN packet. assertion of a Receive FIFO Not Empty Flag Signal 

Accordingly, in step 152, the packet size word received from (RFFNempL). At this point, as shown in step 170, date is 

the SLMAC 142 is loaded into the Trananit Packet Size jead from the RDSFRMR 143. In step 171, the Preamble 

Counter 1404. Alternatively, the packet length of a LAN Detect Logic 1422 monitors the sequence of data being read 

packet may also be determined within the LRDFRMR 140. to determine whether there is a preamble. If a preamble is 

In step 153 the Transmit Packet Size Counter 1404 is not detected, then data may simply be discarded as shown m 

decremented ^e data is written to the Transmit FIFO step 172. If, however, there is a preamble detected, then the 

1406 Such operation would typicaUy continue until the process proceeds to step 173 in which the preamble is loadea 
pa^et count ^reaches zero, indicated by PKT CNT-0. 33 into the Receive FIFO 1424. AdditionaUy, the p^^^^^^ 

However if there is a transmit error, or if the Transmit FIFO word, previously referred to as Packet Length Field U7. is 

becomes fall, the process may proceed to step 154 in which toaded into the Receive FIFO 1424, as well as the Packet 

an Error Latch is set. Then, if the Transmit FIFO is fiiU. step Size Counter 1426, step 174. 

155 shows that daU is written even though the Transit in step 175, the words of the data ^^ceivedfrom the 
FIFO 1406 is full. In one embodiment, the data is actually 40 RDSFRMR 143 are toaded into the Receive FIFO 1424 

discarded in step 155. From step 155, if the Transmit FIFO while decrementing the contents of the Packet Size Counter 

1406 is not stUl full, then the process can proceed to step 153 1426 and monitoring if it has expired to a count of zero, 

again. Alternatively, if the packet count reaches zero prior to which indicates the end of the padcet has been readied. In 

the Transmit FIFO 1406 becoming full, than the process this example, the data is received from the RDSFRMR 143 
proceeds to step 156. 45 as 16-bit words. Various error indications may also be 

In step 156. the Transmit Error Uteh (TXER) is accessed monitored during step 175. For example any error fla^ 
todett^e ^hethertherewasatransmit error. If there^ provided by the RDSFRMR "i^^ J>-_7°fJ^^• 
noerror,theninstep 157,twobitsof theTransmitFIFOmay AdditionaUy, the R^^^^^v^ ,^P^y ^.^ ^^^^n 

^ to indicate that the data transfer was successful. FRMR may be monitored (RJ^^^), as well as the full 
^Stema^vdT^there was a transmit error, then two bits 50 flag of the Receive TOO 1424 (RXFFflag). ^th^^^^^^ 

from the Transmit FIFO may be set to indicate that an error FIFO flags are set, then the process may P^<^ step 176, 

occurred, step 158. After either step 157 or step 158, the in which a Receive Error Uteh is set, and "^^^ J^; 

process returns to step 150, in which the system awaits new in whidi the process waits until the contend of Pa^et 

dl from the LAN Wa the SLMAC 142. Size Counter 1426 decrements. Once thcre^ no 

RG 16 depicts Steps of a process performed by an 55 to be baded, as indicated by the contend of the Padcet S« 

RG. 16 depias ^^^^ J'^T^ y^ ronxiol Lome Counter 1426 being equal to zero, the Receive Error Latch 

cmbcxbment of the Transmit j^^^^ ^ ^hedced to determ^e whether an error has occurred (step 

1410. FoUowmg a {^^^ °^ .^f^ it^?^ no error has occurred, then the last word may be 

transmit pulse is provided to the RDSFRMK 143 in s^ep iw. . Pftrewe FIFO 1424 includine setting error 

i^om ™m <^i^«tor 14W is p^vided to U.e Receive W24 wiU. e^^^^ U> m^c^e 

WJSFRMR 143 via the Transmit Register 1412. TTiis wiU enoi has occurred From cuher step 179 or 180. the process 

cause the RDSFRMR 143 to provide a fill pattern in each proceeds back to step 17U. ^ ^ u o • 

s^veSPrStocribed previously, oiriog step 161. 6S HG. 18 sho^« the pro«sssi^s performed by the Receive 

HFO l^moaitored to determine whether FIFO Read Control Logic 1430. ImUally. as shown m Sep 

fis ftSrriSedby an assertion by signal TXFFNEFL 181. the process is idle until a signal is received mdrcatmg 
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that the Receive FIFO is not empty (RXFFNEMPL). Once 
sucb a sigoal is received, in step 1^, a signal may be 
provided to the SLMAC 142 to indicate that there is valid 
data which is being received from the RDSFRMR 143 by the 
LRDFRMR 140. In the example shown in FIG. 14, this is the 
Signal RXDV Also, during step 182, the data which is in the 
Receive FIFO 1424 is provided to the SLMAC 142 via the 
Receive Register 1432. As indicted with respect to FIG. 17, 
the Receive FIFO 1424 may contain error bits indicating 
whether an error has occurred during the reception of data 
from the RDSFRMR 143. Accordingly, these error bits are 
checked in step 184. If there is no error, than in step 185 the 
final word of the data packet is sent to the SLMAC. 
Alternatively, if there was an error bit set, then a fill pattern 
may instead be sent to the SLMAC and a Receive Error 
Signal may be inserted (RXER) to the SLMAC 142, as 
shown in step 186. Following cither step 185 or 195, the 
Receive Data Valid Signal RXDV may be deasserted. 

As described above, some SONET Framers/Deframers 
may provide a native format transnit capability, as well as 
other transmit capabilities (e.g., ATM cell framing). In a 
particular embodiment that implements the SONET Framer/ 
Deframer as PMC-Sierra Part No. PM5355, an option is 
provided in which ATM cell processing is disabled and raw 
data is either inserted or extracted to or from the SONET 25 
payload. To use the PM5355 in this mode, several register 
bits may be set to the respective values shown below; 
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Bits 




Register Name 


Vahic 


CDDB 


OxSC 


RACF GFC/Misc Cbntiol 


1 


HCSADD 


0x50 


RACF Control 


0 


HCSPASS 


0x50 


RACP Control 


1 


HCSB 


0x60 


TACP Control 


1 


HCSADD 


0x60 


TACP Control 


0 


HCSPASS 


0x60 


TACP Control 


1 


PASS 


0x50 


RACF Control 


1 



30 



40 



50 



Such functionality may also be designed into a single 
ASIC which encompasses the functionality of the RDS- 
FRMR 143 and the LRDFRMR 140 shown in FIG. 14. 
Similarly, the functions described above may be allocated to 
any of several architectural elements and combinations of 
hardware, software and firmware. For example, all or any 
portion of the fiinctionality described with respect to FIG. 14 
may be implemented as a general purpose processor which 
runs software to provide sucb ftinctionality. 

FIG. 19 illustrates another embodiment of the invention, 
in which a data framer 192 determines the packet size of a 
packet to be transmitted, so that this function need not be 
performed by a media access controller. As with the earlier 
examples, the packet size may be defined in one embodi- 
ment as a number of bytes. As illustrated in FIG. 19, the data 
framer 192 also provides synchronization between a SONET 55 
framer/deframer 191 and a media access controller 193, so 
that these two devices may operate asynchronously and at 
different speeds. 

FIG. 19 depicts more detail of this alternative SONET/ 
LAN INTERFACE 73* (similar to interface 73 in FIG. 8). A 
SONET line transceiver 190 provides a physical interface 
with the SONET network. Coupled to the transceiver 190 is 
a SONET framei/deframer 191. At the opposite end, a LAN 
media access controller (MAC) 193 has one interface 
coupled to the LAN. "LAN to raw data framer** 
(LRDFRMR) 192 provides the interface between the framer/ 
deframer 191 and the MAC controller 193. 



In this embodiment, LRDFRMR 192 iixludes a transmit 
buffer 194 and transmit packet size control module 195. The 
control module 195 receives a LAN packet from MAC 
controller 193. and tran^ts the packet to buffer 194 where 
it is stored. The control module 195 determines the size of 
the LAN packet once it has been completely stored in buffer 
194. Such a feature eliminates a need for the MAC controller 
193 to determine the size of the LAN packet and to append 
the packet length field to the LAN packet. LRDFRMR 192 
also includes a receive buffer 196 that receives SONET 
packets from the SONET framer/deframer 191, via receive 
synchronization module 197. In the event that the SONET 
framer/deframer 191 and the MAC controller 193 operate 
asynchronously or at different speeds, the receive buffer 196 
stores at least a portion of the SONET packet prior to it being 
passed to the MAC controller 193, so that module 197 may 
provide the received packet at the appropriate speed and 
time to the MAC controller 193. 

FIG. 20 is a process flow diagram of transmit mode 
operation of LRDFRMR 192. In step 201, LRDFRMR 192 
begins receipt of a LAN packet from the MAC controller 
193. In step 202, LRDFRMR 192 begins storage of the LAN 
packet into the transmit buffer 194. While the LAN packet 
is being stored in buffer 194, a counter is incremented (step 
203). In one embodiment, MAC controller 193 generates a 
transmit enable signal IXEN while sending the LAN packet. 
While this signal is asserted data from the MAC 193 is 
stored in the buffer 194, and the control module 195 incre- 
ments the cotmter to monitor the size of the LAN packet 
being stored. Once the LAN packet has been completely 
stored in buffer 194 (which may be indicated by the TXEN 
signal being de-asserted), the counter value may be used as 
the packet length (step 204). Once the packet length has 
been determined, a preamble, packet length and the LAN 
packet data itself may be transmitted to the SONET framer/ 
35 deframer 191 (step 205). 

Operation in the receive mode of the LRDFRMR 192 is 
illustrated in FIG. 21. In step 210, the receive synchroniza- 
tion module 197 detects a SONET packet in the raw data that 
is received from the SONET framer/deframer 191. In one 
embodiment, the SONET data rate is 155.52 bits/sec, which 
yields an effective rate of 19.44 Mbytes/sec at a continuous 
rate. However, the effective data rate which an exemplary 
MAC controller may receive data is only 12.5 Mbytes/sec. 
TTierefore, it may be advantageous to provide a buffering 
mechanism such as buffer 196 to allow for this data rate 
difference. Thus, in step 210, the SONET packet in the raw 
data is received from the SONET framer/deframer 191 at a 
first data rate. In step 212, the receive synchronization 
module 197 begins storing the packet in the receive buffer 
196 as the data is being received from the SONET framer 
191. As with earlier embodiments, the detection of the 
padcet may be performed by a preamble detector. In step 
214, the synchronization module 197 transfers data from the 
receive buffer 196 to die MAC controller 193 at a second 
data rate that is compatible with the MAC controller 193, 
uiUil all of the packet is transmitted. 

In one illustrative embodiment, the SONET framer/ 
deframer 191 is a PMC Sierra device (Part No. PM5347), 
each of the transmit buffer 194 and the receive buffer 196 is 
a 4Kx8 First In, First Out (FIFO), and the transmit packet 
size control module 195 and the receive synchronization 
module 197 are both implemented within an Actel one-time 
field programmable gate array (FPGA) with 20,000 gates 
(Part No. 32200 DX-1). With FIFOs of this size, this 
embodiment can support packet lengths of 4096 bytes of 
Fast Ethernet packets (100 M/byteVscc) over a SONET STS 
3-C fiber at 155 Mbytes/scc. 
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FIG. 22 is a detailed illustralion of the aliernative 
SONET/LAN interface 73*; in particular, detail is provided 
regarding a FPGA or ASIC (AppUcation Specific Integrated 
Circuit) embodiment of the transmit packet size control 
module 195 and the receive synchronization module 197 of 

no. 19. 

In this embodiment, an ASIC 220 provides an interface 
between a MAC controller 222, x^^ch is also coupled to a 
LAN 221. and a "Raw Data to SONET Framer" 



In the receive mode, preamble detect logic 250 detects 
that a preamble has been received by comparing the incom- 
ing data with a known preamble value, and delects that a 
start of a packet has been received by comparing the 
incoming data with a known SUrt Of Field (SOF) delimiter 
value. Preamble register REG 1 (251) stores the known 
preamble value (e.g.. 55H) and preamble register REG 2 
(252) stores the known SOF value delimiter (e^^ SDH), so 
that the preamble detect logic can access these registers for 



(RDSFRMR) 223. The ASIC 220 refcned 10 herein may be these known vahies. The preamble detect logic also activates 
implemented as an FPGA or an ASIC, or as a combination receive write (RX WR) slate machine 253. Tbe packet 



of discrete devices. In at least one embodiment it is imple- 
mented as a one-time programmable FPGA. In another 
embodiment, it is implemented as a re-programmable FPGA 
and is further coupled to a non-volatUe memory device and 
circuitry to program the re-programmable FPGA from the 
memory device upon power up of the circuit. 
The RDSFRMR 223 is further coupled to a fiber optic 

transceiver 224, whids provides an interface to the SONET ^^^^^ _ ^ 

network 218. A reference clock 225 is also coupled to the ^ 222 via register REG 10 (259), multiplexer MUX 4 

RDSFRMR 223, and provides a 19.44 MHz reference (260), register REG 11 (261), multiplexer MUX 5 (262), and 
AdditionaUy, a second reference clock 226 provides a 25 ^^^^^ reg 12 (263). The RX RD counter 258 may also 
MHz reference to the ASIC 220. In this embodiment, a 4Kx8 ^^nt^ol MUX 4 (260) to provide the preamble from pre- 
transmil FIFO (TXFIFO 227) provides the functions of the ^^^^ ^ ^251) and the SOF delimiter from preamble 
transmit buffer 194 of HG. 19, and a 4Kx8 receives FIFO ^ ^ (252). Register REG 11 (261), together with multi- 
(RXHFO 228) provides the functions of the receive buffer ^^^^^ ^ (262), provides a translation from 8-bil bytes 



the receive write (RX WR) slate machine 253. Tbe packet 
length field, which typically foUows the SOF delimiter, is 
stored in a receive write (RX WR) counter 254. which data 
may also be provided to the RX WR sUtc madiine 253. 

The packet data is stored in the receive FIFO 228 via 
register REG 8 (255), multiplexer MUX 3 (256). and 
register REG 9 (257). Once there is data in the receive FIFO 
228, the receive read (RX RD) counter 258 controls the 
receive FIFO 228 to provide the receive packet data to the 



196 from FIG. 19 

As with earlier embodiments, the functionality ^own in 
FIG. 19 may alternatively be provided by discrete circuitry, 
by software modules operating on a general purpose or a 
special purpose computer, or any combination thereof. 

In operation, a ^/fe-bit Converter 229 within ASIC 220 
receives LAN packets from the MAC controller 222, and 
provides this data through the Multiplexer TXWRDPMUX 



30 



to 4-bit mWles. 

As iudicated in FIG. 22, various registers and additional 
inputs on many of the multiplexers may be used in combi- 
nation to provide diagnostic capability for various segments 
of the ASIC 220. 

Having thus described at least one iUustrative embodi- 
ment of the invention, various modifications and improve- 



Ui^LU- VI. • - 

y,^,^ ^ . , uients will readily occur to those skilled in the art and are 

230 and register REG 1 (231) to the trananil FIFO 35 Amended to be within the scope of the invention. 
While the packet is being loaded, the iraiKimt right (TX 
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WR) state machine 232 controls a 16-bit counter 233 to 
increment whUe the packet is still being stored (i^., while 
transmit enable TXEN is asserted). The V^H Converter 229 
also translates the 4-bit nibbles received from MAC con- 
troller 222 into 8-bit bytes using register A (234), register B 
(235), and input register INREG (236). Once the data is 
loaded, the value in the 16-bil counter 233 is stored in a 
packet count queue FIFO 237, and also in the transmit read 
(TX RD) state madiine 238 which controls the trananit 45 
FIFO input register (TXFIFOIN) 239 to provide synchro- 
nization between the transmit FIFO 227 and the RDSFRMR 
223. AdditionaUy, register REG 3 (240) stores the value 
indicative of the packet length, so that a packet length field 
may be provided to the RDSFRMR through the MUX 1 
(241) and transmit FIFO output register (TX FIFOOUT 
REG) 242. Multiplexer MUX 1 (241) also provides the 
packet data from the transmit FIFO 227 via the trananil 
FIFO input register 239 and also provides a fill pattern from 
the fill pattern register 243 when desirable. 

Additionally, if an error is detected in the data stored in 
the transmit FIFO 242, then a bit may be set in a transmit 
error registo: (TXERR REG) 244, which in turn controls the 
multiplexer MUX 1 (241), to receive inverted data for the 
^ last byte of the packet data, which will in turn cause a CRC 60 
error when the packet is ultimately received. 

Once the TX RD down counter 245 has reached a value 
of zero, the TX RD state machine 238 determines that the 
transfer FIFO 227 has been emptied. The transmit receive 
(TX-RX) pulse generator 246 provides signals which in one 
embodiment controls light emitting diodes (LEDs) to indi- 
cate that data is being either transmitted or received. 
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Acconlingly, the foregoing description is by way of example 
only, and not intended to be limiting. 
What is claimed is: 

1. An apparatus for transmitting data in packets having a 
first format dictated by a first protocol from a first network 
to a second network, comprising: 

means for receiving a first packet of daU in the first format 
from a source on the first netwodc, the first packet of 
data having a variable length; 
means for translating the first packet to a second packet of 
data which is a synchronous transport frame by direcdy 
inserting the first packet of data in the first format and 
a length of the first packet into the second packet of 
data; and 

means for trananitting the second packet across a third 
network which is a SONET network and is coupled 
between the first network and the second network, so 
that the second packet is received at the second net- 
work. 

2. The apparatus of claim 1, wherein: 
the first uetwork is a local area network; and 
the means for receiving includes means for receiving the 

first packet from the local area network in a frame 
format which is native to the local area network. 

3. The apparatus of claim 1, further comprising means for 
buffering the first packet of data to provide buffered daU and 
means for detennining the length of the first packet based 
upon the buffered data. 

4. The apparatus of claim 1, wherein there is a transmis- 
sion rate difference between the first and second networks 
and further comprising: 



06/:S5/2003, EAST Version: 1.03.0002 



6,12 

15 

second means for receiving a third packet of data from a 
source on the second networic; 

means for buffering the third packet to account for the rate 
difference; and 

second means for transmitting the third packet to a 
destination on the first network over the second net- 
work. 

5. The apparatus of claim 1, wherein the means for 
transmitting inchides means for transmitting a fill pattern 
across the third network when no packets are received from 
the first network. 

6. In a computer-implemented method for transmitting 
packet data received from a first network in a native LAN 
format across a second network in a synchronous transport 
fiame, the frame including a tran^rt overhead and a 
synchronous payload envelope (SPE), the method compris- 
ing the step ot 

trananitting a variable length packet received from the 
first network over the second network in the synchro- 
nous transport frame, where the SPE of the synchro- 
nous transport frame further includes a packet length 
field and the variable length packet in the native LAN 
format. , . 

7. The method of daim 6, the method fiirther comprismg 
a a step of transmitting a fill pattern when there are no 
pending frames to be sent in the synchronous transport 
frame. 
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8. The method of claim 6, further comprising a step of 
determining a packet length of the variable length packet. 

9. The method of claim 8, wherein the step of determining 
the packet length includes receiving and storing the variable 

^ length packet in an iixput buffer. 

10. The method of claim 6, wherein there is a transmission 
rate difference between the first and second networks and 
further comprising a step of receiving the packet from the 

10 first network at a first rate and wherein the step of trans- 
mitting is at a second rate. 

11. The method of claim 10, wherein the step of trans- 
mitting inchidcs a stq) of buffering data from the first 
network to account for the rate difference. 

12. The method of daim 10, further comprising a step of: 
transmitting the synchronous transport frame to a desti- 
nation on a third network over the second network. 

13. The method of daim 6. fiirther comprising the step of 
20 receiving the synchronous transfer frame at a third network. 

14. The method of claim 13, wherein the step of receiving 
includes a step of extracting the variable length packet from 
the synchronous transport frame. 

15. The method of claim 13, wherein the third network is 
^ a LAN. 
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